Great! I did pass part 1 of my LPI 101 test, but also having a bit of a crisis with my computer, so I'm swamped today trying to fix it.

Patchlevel ten contains the changes for the blank screen issues. I've disabled support for external devices in xbmc when in RetroRig Mode: beaumanvienna/xbmc@287fec8

What exactly does this mean? Does this mean if any other program or device tries to steal the display, it is not allowed? Good as well that Helix is in, I didn't even think of looking at that yet.

When it comes to packaging RetroRig itself as, I would like to ask you, if you could take over this task. The setup needs to detect which installation method is used. All file install and remove operations needs to be checked. Some files that we copy in retrorig_setup.sh are already installed from the Debian package. I would suggest that we keep both method of installing alive.

Are you asking me to keep retrorig_setup.sh up to date with what you do in the debian package?

Ok, i'll take a look at your comments and work on this tomorrow or later today. I'm sorry I am not as advanced in some of this stuff, so to appreciate you still sticking with this instead of forking permanently. I will dedicate time tomorrow to digging into recent changes you have done.

Ok, i'll take a look at your comments and work on this tomorrow or later today. I'm sorry I am not as advanced in some of this stuff, so to appreciate you still sticking with this instead of forking permanently. I will dedicate time tomorrow to digging into recent changes you have done.

Hey Professor, this is all about learning by doing. Look for example how the folks from ppsspp currently dissect my code: https://github.com/hrydgard/native/pull/238/files
You had an awesome idea with RetroRig, you did a hell of job so far, it's all nicely documented and promoted. No way I would split this into my own fork. Just for your information, I'm not doing this to have some kind of a hyper-console at home. I'm actually doing this to contribute to the open source community. The new way of installing RetroRig is just another step to make people use our project. Once we can distribute it as regular package, we can propose it to upstream maintainers, or for the software center. But until then we must get it real slim and fit. The online scraping for example needs some improvements, save states should be saved in the RetroRig folder, so that all files that need backup are in one place. For pcsx2 I would like to get a bios file chooser directly integrated in the setup. When it comes to Debian based platforms, I would say we already got something like 90% of the work.

OK, anyways, if you need any help or further clarification, just let me know!

Since you cut out supplemental in the Debian package of retrorig-setup, I will need to package the small C utility I use to gather the PS3 MAC address in pure form:

# Set PS3 Blu MAC value with the "joydetect" C program
# Credit for this goes entirely to http://www.reddit.com/user/ElFeesho
 PS3_MAC_BLU=$($scriptdir/supplemental/joydetect /dev/input/js0 | awk -F'[^:[a-zA-Z0-9]*' '{print $6}')

This will be a good first package, since it's just a small compile, very quick. Once this is done and uploaded, i'll change both the Debian package, and the git setup script to use this program from my PPA. A good first step ? I am starting to get what you mean when you note removing supplemental in the build script etc.

But first I will built retrorig-setup into my PPA so I have that there first, then I'll get to packaging the joydetect utility.

Awesome! :-D

But first I will built retrorig-setup into my PPA so I have that there first, then I'll get to packaging the joydetect utility.

Sounds good, we can keep the supplemental folder for the first build attempts, package your helper program later and then remove supplemetal/.

I was a little busy myself today. First I installed RetroRig on my production Mint system, last time I did this was in June or July. It still had some special PPA for mednafen installed, which now supports a newer version than ours. I packages mednafen again with prefix "1:0.9.36.2.2", due to the leading "1:" our package is now superseeding everything else that's out there.

Also, on my Mint rig dolphin-emu didn't got raised. Don't ask me why, I actually tested this this week. Anyway, I patched it with the tiniest patch imaginable, now it works. I've tested the new version both under Ubuntu 14.04 and Mint 17.

I'm glad you took over my work! :-D As always, if you need any support, just ask.

Oh, wait. What you also could do is move joydetect directly to /usr/bin in the fakeroot:

• in the build script move it from RetroRig/supplemental to RetroRig/bin.
• (now you can safely delete the supplemental folder)
• in the rules file you can move it to /usr/bin of the fakeroot with

cp bin/joydetect $(CURDIR)/debian/tmp/usr/bin/

, see here

I forgot to mention that I'm currently working on linking the save state folders of the emulators to the Saves folder in /home/user/RetroRig.. :-D

Oh, wait. What you also could do is move joydetect directly to /usr/bin in the fakeroot:

I think I am going to package the utility, especially since it will be good practice, an the utility won't really change. It was a helpful C program someone helped contribute, and he will be noted in the changelog of course. I first have to sort out my gpg and ssh keys for Launchpad, upload the retrorig-setup package, and then start looking at packaging Joydetect.

How do you check the status of a package being uploaded to your PPA? just the terminal output? Before I noticed my gpg key wasn't listed (it was from a 32 bit dev VM), I synchronized it, but the build script still uploaded.

Do you wish to upload the source package?    y
Checking signature on .changes
gpg: Signature made Sun 12 Oct 2014 05:10:01 PM EDT using RSA key ID C08DD74E
gpg: Good signature from "Michael DeGuzis <[email protected]>"
Good signature on /home/pkgdev64/packaging/retrorig-setup/retrorig-setup_0.9.5.1_source.changes.
Checking signature on .dsc
gpg: Signature made Sun 12 Oct 2014 05:09:44 PM EDT using RSA key ID C08DD74E
gpg: Good signature from "Michael DeGuzis <[email protected]>"
Good signature on /home/pkgdev64/packaging/retrorig-setup/retrorig-setup_0.9.5.1.dsc.
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading retrorig-setup_0.9.5.1.dsc: done.
  Uploading retrorig-setup_0.9.5.1.tar.gz: done.        
  Uploading retrorig-setup_0.9.5.1_source.changes: done.
Successfully uploaded packages.

I think I am going to package the utility, especially since it will be good practice, an the utility won't really change. It was a helpful C program someone helped contribute, and he will be noted in the changelog of course. I first have to sort out my gpg and ssh keys for Launchpad, upload the retrorig-setup package, and then start looking at packaging Joydetect.

Alright. You will need to provide a Makefile. If it's just one line for gcc -o joydetect main.c you could use the dummy Makefile and put it under all:.

How do you check the status of a package being uploaded to your PPA? just the terminal output? Before I noticed my gpg key wasn't listed (it was from a 32 bit dev VM), I synchronized it, but the build script still uploaded.

You will get an email, if it was accepted (or rejected). The rest you can follow on launchpad.

This is my new code for linking the save states, it seems to work: beaumanvienna@9f0d42b

Nice Sunday!

ok, ill give these two packages a try. I will try to update the wiki for the packaging guide If I can, since I do want to include setup info like packages needed, and how to setup Launchpad and GPG/SSH etc.

I wish I was a pro on this stuff like you haha.

There's also an example autoconf project in our Box box. It will force you to provide all necessary files for an open source project like the licence and so on. Then you get the classic way configure && make && make install. Debuild will detect the autoconf method automatically. Just make sure you can compile it manually with make before you run debuild.

Could you post a link to your repro?

https://launchpad.net/~mdeguzis/+archive/ubuntu/retrorig

Ok, got the email for retrorig-setup:

Accepted:
 OK: retrorig-setup_0.9.5.1.tar.gz
 OK: retrorig-setup_0.9.5.1.dsc
     -> Component: main Section: games

Upload Warnings:
No copyright file found.

retrorig-setup (0:0.9.5.1) trusty; urgency=medium

  * RetroRig is a suite of console emulators embedded in a
    home theater program. It features more than 15 console types,
    and supports XBox360, PS3 and Wii motion control gamepads.

    Run "sudo retrorig-setup" to start the installation.

    Homepage: https://github.com/ProfessorKaos64/RetroRig

    Copyright Libregeek.org 2014
    Copyright JC Techno Labs 2014

  * Initial upload for PK's RetroRig repo

--
https://launchpad.net/~mdeguzis/+archive/ubuntu/retrorig
You are receiving this email because you are the uploader of the above
PPA package.

I will start looking at your hints for the joydetect C utility and this week I will assess your comments about the script vs. the debian package (such as the removal of supplemental). I noticed the line about no copyright file. Was I supposed to put the GPL V3 somewhere?

Going to take a break and then come back to this. Maybe play some FFVII

What would help me the most, like we were going to do last week or before, is have a chat on IRC, so I can go through the process and the debian files and ask questions in real time. I never see ya on IRC any more haha. If that's tough with your schedule, I will make an email with questions.

Side note, we should make a $DATE real time variable to fill in the date during our build scripts rather than enter:

 -- Michael DeGuzis <[email protected]>  Thu, 2 Oct 2014 21:15:00 +0200

Manually.

There's also an example autoconf project in our Box box. It will force you to provide all necessary files for an open source project like the licence and so on. Then you get the classic way configure && make && make install. Debuild will detect the autoconf method automatically. Just make sure you can compile it manually with make before you run debuild.

I started the build script and some of the debian files under the joydetect folder in the beta supplimental directory. I got a little lost with what I found in the autoconf example archive you have on box.net. Wasn sure where to put those files, let alone modify them (which I probably could make out eventually.) I will take another look at http://packaging.ubuntu.com/html/packaging-new-software.html to see where some of this fits in.

Congratulations to your first successful upload!

I will start looking at your hints for the joydetect C utility and this week I will assess your comments about the script vs. the debian package (such as the removal of supplemental).

I support your idea of providing a dedicated package for joydetect. No binary blobs! It will help us to find acceptance for getting into the Software Center. I'm going to provide a new helloWorld example project done with cmake. I actually prefer cmake over autoconf. Firstly I like the separation of source and build files, all it takes to start from scratch is to delete the build folder with cmake. Moreover, the syntax of cmake is easier compared to the cryptic style of autoconf.

I noticed the line about no copyright file. Was I supposed to put the GPL V3 somewhere?

Yes, I think so. This is a good example of why I passed this work package on to you. Clearly a decision of the lead architect in our project! Could you also give the changelog text a little bit of a native English touch?

Just a side note: Speaking of native languages, did you plan anything on language support in the project?

What would help me the most, like we were going to do last week or before, is have a chat on IRC, so I can go through the process and the debian files and ask questions in real time. I never see ya on IRC any more

Yes, sure! Maybe Fri or Sat evening? From Sun 19th until Thu 23rd I'll be on an Asia trip with reduced availability for this project.

Side note, we should make a $DATE real time variable to fill in the date during our build scripts rather than enter:

The command dch -i generates a changelog and opens it in a text editor. I'm too lazy to fill it out everytime again, so I'm using sed. But I had a lot of "changelog"-accidents lately, I always forget to update it. This really needs to change, so any improvements are welcome. We should actually put the release text to a variable as well. I noticed you managed to not ignore EDT, good :-DDD

I got a little lost with what I found in the autoconf example archive you have on box.net. Wasn sure where to put those files, let alone modify them (which I probably could make out eventually.)

Please post the compile command. The dummy Makefile represents the minimum targets required by debuild, make clean and make all. The install would then be manually in the rules file by override_dh_install. Of course you can add alternatively a make install to the Makefile. But it's probably more advisable to use autoconf or cmake. These tools take care of a lot of things you would normally not think about. Like stripping the binary for example. I was thinking about making a tutorial repository at Github for a longer time now, maybe I get to this this week.

All in all great work!

Ahh, one more thing. To detect if our setup script runs in a git cloned folder or resides in a system folder, shall we just keep the file retrorig_setup.sh in git and renaming it to retrorig-setup in the deb package? Then we could test $0 and set the paths for the scriptmodules accordingly.

Hey Professor!

Here's some feedback to your packaging efforts:

Makfiles always need a TAB before the command:

all:
→gcc -o joydetect joydetect.c

However, I've uploaded a cmake example project for joydetect to our Box box, so you can delete debian/Makefile. The cmake project contains just two simple CMakeLists.txt files, one in the root directory, and one in source. Totally easy to understand. As always with cmake, the commands (in the project root directory) are

mkdir build
cd build
cmake ..
make
sudo make install

Before you run debuild always try to build manually. For complex projects it's recommended to do this on a blank VM, this way you'll get the dependencies straight.

You'll need to add cmake to the build-dependency lists in joydetect.dsc and debian/control, as well as to the build script itself.

Some comments to your build script:

• in build-joydetect-ppa.sh and changelog there are still some occurrences of the former package name getpos
• you are using quilt in joydetect.dsc and debian/source/format. I never managed to make this work. (But every package maintainer apparently does :-D ) I'm always using native, this way I can upload a complete source package every time I upgrade to a newer version. But let me know how this works for you!
• you are using different Standards-Version tags, in joydetect/debian/control it should be 3.9.5

The rest is OK! Good luck!

Ok JC, did little bit of work to the build script for joydetect. I took a look at http://xpressrazor.wordpress.com/2013/05/09/creating-ubuntu-packages/ to get an idea of cmake. But .. i'm sure I am a bit backwards on the script, so thank you for helping me figure this out.

Good tutorial, very comprehensive! For a Qt app I would use qmake though, it is optimized for this framework.

Some comments to your script:

• the dsc file needs to be moved one folder up, to ~/pkg-build-tmp/joydetect/joydetect_1.1.0.dsc, after the git-cloning
• you need to restore the rules and changelog files from yesterday, they were OK already (In the changelog you deleted the leading and following spaces in the last line. Stupid, how picky these tools are.)
• skip the copy changelog, control, rules and format
• before the final debuild you need to cd back into the project directory

And Alex is your mothers brother!

OK so I almost got it hahaha. Everything I get except 2 things. And some of this is due to my curious nature of attempting to know everything which is why the irc session Saturday of you have the will be really helpful.

The page I linked had that rules file laid out for cmake. Are you saying those lib lines are for at based cmake or qmake? And also, why do I need to cut out the changelog and such. Is that because I have it in got already? That is one thing too...balancing what we keep in supplemental and github. No problem just things like this will be clearer once I do this a few times.

Thank you for the feedback!

On October 14, 2014 2:34:15 AM EDT, Jens-Christian [email protected] wrote:

Good tutorial, very comprehensive! For a Qt app I would use qmake
though, it is optimized for this framework.

Some comments to your script:

• the dsc file needs to be moved one folder up, to
  ~/pkg-build-tmp/joydetect/joydetect_1.1.0.dsc, after the git-cloning
• you need to restore the rules file from yesterday, that was OK
  already
• skip the copy changelog, control, rules and format
• before the final debuild you need to cd back into the project
  directory

And Alex is your mothers brother!

---

Reply to this email directly or view it on GitHub:
#127 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Eventually when you or me add/edit the packaging wiki page more, on etching that would help is a tree command view of the whole thing at the start so I and people understand where all of the pieces fall in place if that males any sense. This could be helpful for different types we write up for, may it be autoconf , cmake, or more. When everything is said and done, this will be greatly helpful to me and others to help contribute.

When most of this is done with, I likely will lick back up my python book. Just a lot going on right now.

On October 14, 2014 2:34:15 AM EDT, Jens-Christian [email protected] wrote:

Good tutorial, very comprehensive! For a Qt app I would use qmake
though, it is optimized for this framework.

Some comments to your script:

• the dsc file needs to be moved one folder up, to
  ~/pkg-build-tmp/joydetect/joydetect_1.1.0.dsc, after the git-cloning
• you need to restore the rules file from yesterday, that was OK
  already
• skip the copy changelog, control, rules and format
• before the final debuild you need to cd back into the project
  directory

And Alex is your mothers brother!

---

Reply to this email directly or view it on GitHub:
#127 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

That is one thing too...balancing what we keep in supplemental and github. No problem just things like this will be clearer once I do this a few times. [..] And also, why do I need to cut out the changelog and such. Is that because I have it in got already?

My approach to this was to keep the RetroRig specific things in the supplemental folder. This is in the first place all Debian files with special placeholder tags. However, your idea to put the debian folder into the git project makes it more transparent for people outside RetroRig. So my suggestion would be to leave the files in the github repository, maybe change the placeholder tags to actual entries, and maybe even move the dsc file one folder up (or the complete project except the dsc file one folder down). This way everybody could run debuild manually w/o the script. In folder supplemental/debian you place the Debian files that contain placeholders, and keep the down copying in the build script.

And some of this is due to my curious nature of attempting to know everything which is why the irc session Saturday of you have the will be really helpful.

I'll be there!

The page I linked had that rules file laid out for cmake. Are you saying those lib lines are for at based cmake or qmake?

If he had used qmake instead of cmake, probably his tinkering work wouldn't have been necessary in the first place.

No matter if autoconf, cmake or qmake, these systems already scan your system for such dependencies (include and library paths, etc.). Your rules file from yesterday was extremely simple, this makes it less prone to break on a different system, like the build server.

When most of this is done with, I likely will lick back up my python book. Just a lot going on right now.

I have background scraping in RCB on my wish list ;-)

Yea I k ow you can do that on startup of RCB, which has the code, the. I assume you'll make a job worker to tie it all together.

On October 14, 2014 6:55:59 AM EDT, Jens-Christian [email protected] wrote:

When most of this is done with, I likely will lick back up my python
book. Just a lot going on right now.

I have background scraping in RCB on my wish list ;-)

---

Reply to this email directly or view it on GitHub:
#127 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

so I seemed to have done a better time building , but still have some errors/warnings:

Now running lintian...
W: joydetect source: debhelper-but-no-misc-depends joydetect
E: joydetect source: package-uses-debhelper-but-lacks-build-depends
W: joydetect source: package-needs-versioned-debhelper-build-depends 9
W: joydetect source: missing-license-paragraph-in-dep5-copyright gpl-3 (paragraph at line 5)
W: joydetect: missing-depends-line
E: joydetect: copyright-should-refer-to-common-license-file-for-gpl
E: joydetect: extended-description-is-empty
W: joydetect: extra-license-file usr/share/doc/joydetect/licence.txt.gz
E: joydetect: package-section-games-but-contains-no-game
W: joydetect: binary-without-manpage usr/bin/joydetect
Finished running lintian.

I thnk this is because I am not in the right directory for the build, since it seems it is reading the git files (which are incorrect, but show the cp command is not overwriting them from supplemental?).

Is the structure of my git repo and supplemental better? I'm worried about the disconnect between the changelog in github and that of supplemental/. Seems like Then there will be two seperate change logs. Wouldn't it make more sense to keep the change log only in github? if folks need to package themselves, like forking a project, they would pull from git and add their new changelog line, and their changelog would reflect thier changes, and mine would stay the same. idk , i'm all confused now haha. Keeping all our code on github or in one place seems easier, but maybe i'm just not getting it LOL. I always seek the path of least ressistance if I can.

Things like this are why I want to chant over IRC, unfortunately I mayb not be here Saturday :(

W: joydetect source: package-needs-versioned-debhelper-build-depends 9

I see in some controls, there is a line similar to " libgtk2.0-dev (>= 2.16)" in the control file, but your getpos control file reads "${misc:Depends}". Things like that I am not sure on, but yes I could google alot and do reading to learn about all these different things.

Yeah! It runs, great! That's all you need! Upload it!

I'm worried about the disconnect between the changelog in github and that of supplemental/. Seems like Then there will be two seperate change logs.

I know what you mean. Because of this I didn't create a debian folder in the git repositories.

Keeping all our code on github or in one place seems easier, but maybe i'm just not getting it LOL

No I think you do get it, it's just not that easy. I myself dislike redundancies in the documentation too.

but your getpos control file reads "${misc:Depends}"

I don't know which dependencies are pulled in here either! :-DD

Lintian always complains, that's typical. Maybe there's a rule for upstream packages, that lintian may not complain, if you want to get it into the software center. But we can igonore it for now.

May I ask why you didn't upload the project?

I didn't upload because of lintian so I can do that in the morning if so. I didn't know if things would work so I only did a compile update. I was going to try and fix the errors. It seemed to not matter if I added a version constraint to the dependencies. I'm weird in that I often don't like things like that so I dig and dig to try and fix them. Mainly why I like Linux.

On October 15, 2014 1:51:53 AM EDT, Jens-Christian [email protected] wrote:

Yeah! It runs, great! That's all you need! Upload it!

I'm worried about the disconnect between the changelog in github and
that of supplemental/. Seems like Then there will be two seperate
change logs.

I know what you mean. Because of this I didn't create a debian folder
in the git repositories.

Keeping all our code on github or in one place seems easier, but
maybe i'm just not getting it LOL

No I think you get, it's just not that easy. I myself dislike
redundancies in the documentation too.

but your getpos control file reads "${misc:Depends}"

I don't know which dependencies are pulled in here either! :-DD

Lintian always complains, that typical. Maybe there's a rule for
upstream packages, that lintian may not complain, if you want to get it
into the software center. But we can igonore it right now.

May I ask why you didn't upload the project?

---

Reply to this email directly or view it on GitHub:
#127 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Actually it should be possible to run Lintian w/o any warnings or faults. I mean it's just five lines of code. You could ask in the #launchpad @ freenode IRC channel.

You will then be required to provide a man page. Maybe a good idea anyway...

I am down to 2 errors. OH MAN is Linitian picky about spaces, line breaks and more. But this is a good learning exercise, and it will prepare me if I ever submit something to Ubuntu/Debian. Gotta find out how to do a manpage next. https://lintian.debian.org/tags.html is a great resource, and things like that I will work into the guide aftert this is done.

Now running lintian...
E: joydetect: package-has-no-description
W: joydetect: binary-without-manpage usr/bin/joydetect
Finished running lintian.

Update: Fixed everything :) , I will devote time tomorrow to writing in my experience and such into our packaging guide. Look! It's there ^_^ , free of lintian errors/warnings, complete with manpage. One such thing that helps, is using rst2man, to get proper unix formatting, though you can do without it. I was wondering why some folks manpages looked so cryptic, compared to what you see in the terminal window.

I'll likely fixup retrorig-setup at some point soon. Tomorrow I want to also look at the size of the beta branch and chop out what we don't need. I think it's common that frequent changes build up the .git/ folder a bit.

Perfect! Very good work!

Looks like we need to add your PPA to the install script.

Really, this is a looong list of complaints https://lintian.debian.org/tags.html :-P

I installed your package, awesome man page! :-D

I'll likely fixup retrorig-setup at some point soon. Tomorrow I want to also look at the size of the beta branch and chop out what we don't need. I think it's common that frequent changes build up the .git/ folder a bit.

Sounds good! The package retrorig-setup_0.9.5.2_amd64.deb in your repository is a little chubby with it's 55MB. But installing this compared to cloning the github repro is for a me a difference between 30s and >5min. So I'm really looking forward to this new install method.

Just a side note, the SDL2 version of ppsspp is brilliant. I like it already a lot.